第2章 アジャイルチームの紹介
2.1 アジャイルなプロジェクトはどこが違うのか
アジャイルプロジェクトには三つの特徴がある
きっちりと区別しない役割分担
アナリスト・プログラマー・テスターみたいな役割は存在しない
継続的な開発工程
ウォーターフォールみたいな開発工程は存在しない
チームで成果責任を果たそうとする態度
チーム全体で常に成果責任を果たすことに対して気を配る必要がある
2.2 チームをアジャイルするためのコツ
アジャイル開発の原則
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければならない
同じ仕事場で働く
開発メンバーがリモート環境で離れていても、プロジェクトが始まるタイミングだけでもいいので、同じ場所で働くといい
短い時間でもいいので、同じ場所でコミュニケーションや食事をとることによって、高いパフォーマンスが保てるチームができる
積極的に深くかかわる顧客の存在
お客様と信用貯金をためて開発に積極的にかかわる立ち回りが必要
積極的に深くかかわりたがらない顧客の場合は、顧客の課題を解決できるチームであることを証明して、チームの信用度を高めていく
自己組織化
人に合わせて役割分担をあわせるチームビルディングをしていく
信頼できる人に仕事をまかせて、権限を与えていく。そうすればチームに自己組織化ができていく
アジャイル開発の原則
最良のアーキテクチャ・要求・設計は自己組織的なチームから生み出される
成果責任と権限委譲
成果責任を持てるにように開発チームに権限を適切に委譲していく必要がある
もし開発チームが成果責任を実感できない場合は、今自分がつくっているソフトウェアの挙動をお客様に見せること。そうすることで、フィードバックや不具合を感じることで成果責任が自動的に身に付く
アジャイル開発の原則
意欲に満ちた人々を集めてプロジェクトを構成する。環境と支援を与え仕事が無事に終わるまで彼らを信頼する
職能横断型チーム
職能横断型チーム（Cross-Functional Team）はお客様の要望を最初から最後まで答えれるチームのこと
このメンバーを携えるには、適切なスキルと専門知識が備わっていて、顧客が必要とする機能を提供できる能力がある人
2.3 よくある役割分担
開発チーム
職能横断型チームで顧客が望む機能に関することはなんでもする（アナリスト、プログラマ、テスター、データベース管理者、ユーザーストーリ）
それらの能力を併せ持ったメンバーで構成する必要がある
開発チームを編成する時には、役割分担は基本あいまいな存在であることこを伝える必要がある
以降はアジャイル開発における役割を説明していく
アジャイルなアナリスト
顧客の要望を実装するにあたって、どうやって実現するのかを詳細にまで調べる
アナリストはさまざまなことを実施する必要がある
ユーザーストーリーを描く
ストーリーを実施する
モックアップやプロトタイプの作成
アジャイルなプログラマ
ソフトウェアを開発していく人。
テストをたくさんかいたり、アーキテクチャ設計したらい、CI/CDにも取り組む
アジャイルなテスター
プロジェクト全体のテストをしていく人
テストの自動化
アプリケーションクラッシュのテスト
負荷テストやスケーラビリティをテスト
アジャイルなプロジェクトマネージャー
開発チームの成功にさせるために立ち回る人
ステークホルダーへの報告し、社内の人間関係を円滑にする
上位のプロジェククトメンバーへの期待値調整
いまどうなっているかを追跡する
優れたプロジェクトマネージャーは不在が一週間続いても開発が回る様な立ち回りが必要
アジャイルなUXデザイナ
使いやすく、利便性の高い、魅力的なユーザー体験を提供する人
スクラムマスター
アジャイル開発の原則は考え方を説明して、受け入れていくことを後押しする
2.4 チームメンバーを探すコツ
ゼネラリスト
なんでもできる人。フロント・バックエンドやそれ以外の領域でも責務を全うできる人
曖昧な状況に抵抗がない人
要求・計画などが整っていない環境でも、整理できる人
体を張らないチームプレイヤー
自分を誇張せずに、周りのメンバーで協調していき、お互いに学び合って成長していける人